IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end subscribers will grow, and the inter-personal communication experience will be enriched. This is leading to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) and ETSI TISPAN group to provide IP Multimedia services over mobile communication networks. IMS provides key features to enrich the end-subscriber person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between subscriber terminals (or subscriber terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a subscriber-to-subscriber protocol, IMS allows operators and service providers to control subscriber access to services and to charge subscribers accordingly.
By way of example, FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the subscriber that the subscriber is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. ASs provide services to end users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which ASs should be “linked in” during a SIP Session establishment (or indeed for the purpose of any SIP method, session or non-session related). The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's or subscriber's Subscriber Profile.
IMS users make use of User Equipment (UE) which may comprise or represent any device used for communications. Examples of UEs that may be used in certain embodiments of the described network(s) are wireless devices such as mobile phones, terminals, smart phones, portable computing devices such as lap tops, handheld devices, tablets, netbooks, computers, personal digital assistants and other wireless communication devices, or wired communication devices such as telephones, computing devices such as desktop computers, set-top boxes, and other fixed communication devices.
IMS subscribers are identified in the IMS by both a private user identity [IP Multimedia Private Identity (IMPI)] and a public user identity [IP Multimedia Public Identity (IMPU)]. The IMPI represents the subscriber's subscription, whilst the IMPU is a public identity that can be used, for example, by other users and service providers to contact the subscriber to whom the IMPU belongs. A subscription may have a plurality of IMPUs associated with it, e.g. a given subscription may have an IMPU representing an office contact for the subscriber and an IMPU representing a home contact for the subscriber. The subscriber may define different behaviours for the two IMPUs.
A Ut interface (or more correctly “reference point”) has been specified between the AS and a UE (e.g. 3GPP Technical Specification 23.002). The Ut interface enables a user to manage information relating to his or her services, e.g. creation and assignment of Public Service Identities, management of authorisation policies that are used for example by presence services, conference policy management, etc. The Ut interface allows in particular a user to manipulate Extensible Markup Language (XML) data associated with an AS and which defines how certain services are provided to that user. An example use case is that of MMTel supplementary services, and the manipulation of these services via the Ut interface. MMTel is a multimedia telephony service for subscribers, facilitated by the MMTel AS, and manipulation of XML data via the Ut interface allows subscribers to set and change settings such as call forwarding, call barring, etc. This is discussed in 3GPP TS 24.623 V12, Extensible Markup Language (XML) Configuration Access Protocol (XCAP) over the Ut interface for Manipulating Supplementary Services.
XML documents are handled by XML Document Management Servers (XDMSs), which may be co-located with ASs, e.g. with an MMTel AS. In use, an XDMS stores service data into a Home Subscriber Server (HSS) (as transparent data), which is then retrieved by the AS at service invocation.
ETSI TISPAN has adopted the XML Configuration Access Protocol (XCAP), as specified in IETF RFC 4825 and 2616, for use over the Ut interface and which facilitates the use of HTTP methods, i.e. GET, PUT, and DELETE, to operate on XML data stored in the HSS, via an XDMS. The XCAP protocol defines how XCAP Uniform Resource Identifiers (URIs) are used to identify precise locations within XML documents on the XCAP server. FIG. 2 illustrates schematically the Ut interface in the IMS.
The XML documents defining customer services and settings are handled by the XDMS. A so-called “Sh” interface allows the XDMS to communicate with the HSS using DIAMETER. [This is considered in detail in 3GPP TS 29.328 V11.5.0 Sh Interface Signalling Flows, and in 3GPP TS 29.329 V11.4.0 Interface Based on Diameter Protocol.] A network operator may initially install pre-configured XML data, based upon the standardised XML schema, on a per-user basis into the HSS, and subsequently amend the installed XML data via the XDMS. The management network additionally provides a mechanism whereby a user can edit his/her associated XML document. For this purpose, a Ut client can be installed within the UE and/or within a web portal. As discussed above, the Ut client uses the XCAP protocol to retrieve (either the whole document or a fragment thereof) and amend the XML document (or fragment) associated with the user. It will be appreciated that the XDMS reacts to a retrieval request from a user via the UE or web portal by obtaining the relevant XML data from the HSS and delivering this to the user via the UE or web portal over the Ut interface.
The Ut client fetches the data for the user from the XDMS by sending an XCAP HTTP GET request to the XDMS over the Ut interface. An Aggregation Proxy may be used to authenticate these requests. The XDMS fetches the data from the HSS over the Sh interface and sends it back to the Ut client in a Ut response message. The Ut client displays information and options to the user.
When sending an HTTP request to the XDMS to manipulate the MMTel supplementary services, the UE uses an XCAP Identity that is an IMPU of the user, as defined in [3GPP TS 24.109 Bootstrapping interface (Ub) and network application function interface (Ua), Rel 11]]. The UE may be authenticated to the IMS using, for example, the Generic Authentication Architecture (GAA) involving the Authentification Proxy (AP). When 3GPP GAA is not present, the X-3GPP-Asserted-Identity is used. When 3GPP GAA is present the X-3GPP-Intended-Identity can be used, with the AP replacing the X-3GPP-Intended-Identity with the X-3GPP-Asserted-Identity. The X-3GPP-Intended-Identity is optional and the UE may send it indicating which “alias” of the IMPU the AP should consider for authentification and requests (3GPP TS 33.222 Rel 11 and 24.109 Rel 12).
Although each IMS subscription must be associated with at least one IMPI, a single subscription may be associated with two or more IMPIs. FIG. 3 gives an example of an HSS data model for a given subscription. The example relates to a subscription associated with two IMPIs and six IMPUs. The IMPUs are grouped into three Implicit Registration Sets (IRSs), with the IMPUs of each set being registered collectively. Four different service profiles are specified for the subscription, these service profiles being shared across different IRSs. The service profiles are of course defined in the XML documents stored in the HSS and accessed by the subscribers UE(s) via the XDMS and the Ut and Sh interfaces. The HSS data model for IMPI, IMPU and service profile relationship is considered in 3GPP TS 23.228 IP Multimedia Subsystem (IMS) Rel 11.
It is noted here that IMS subscribers may be fixed line subscribers, rather than mobile (e.g. LTE) subscribers. In this case, a subscriber's private user identity will be an IMSI whilst his or her public user identity will be an MSISDN. Whilst the following discussion relates to the IMPI/IMPU case, it will be appreciated that it relates equally to the IMSI/MSISDN case.
Considering further the Ut interface, a subscriber's UE can access an entire simservs.xml document by including in the (e.g. HTTP GET) request a URI with no node selector, for example as shown in Table 1 below. An example of a successful, 200 OK response to this document granularity GET is shown in Table 2 below.
Alternatively, an individual element (or fragment) from within the simservs.xml document can be obtained by the Ut client by using a node selector (following the node selector separator “˜˜”). For example, to obtain the element communication-diversion and its contents a node selector of simservs/communication-diversion can be used as shown in Table 3 below. An example of a successful 200 OK response to this element granularity GET is shown in Table 4 below.
It will be appreciated from the above discussion that the current approach to manipulating service data makes use of the IMPU (i.e. X-3GPP-Asserted-Identity sent in XCAP) to define the part or parts of a service data block that should be provided to a UE (or operator node). This is adequate for the simple case where, for example, a subscription is associated with a single IMPI and one or more IMPUs. However, the approach is not necessarily appropriate for more complex subscription scenarios such as:                MultiSim (where a single subscription is associated with multiple IMPIs); and/or        Multi-number (where a single subscription is associated with multiple IMPUs),where a service data repository may be shared or unique for an IMPI/IMPU combination, such that providing an IMPU to access the data is insufficient to identity the correct shared or unique service data repository.        
FIG. 4 shows a MultiSim scenario for a given subscription, where both IMPIs are associated with the same IMPU. However, separate repository service data is specified, one for IMPI1 and one for IMPIn. In this scenario, it is not possible for IMPI1 (e.g. UE1) to access its repository service data “A” via the Ut interface by providing only the X-3GPP-Asserted-Identity, i.e. an IMPU, as an IMPU points to both repository service data “A” and repository data “B”. The same applies in the case of IMPIn. This problem is illustrated further in FIG. 5 which illustrates the following signalling:    1. IMPI1 sends a Ut PUT command to update its repository data.    2. AP forwards the command to the XDMS.    3. XDMS sends a UDR with:            Service-Indication AVP==“service indication string”        Public-Identity AVP=X-3GPP-Asserted-Identity=IMPU        Data-Reference AVP=0            4. The HSS is unable to comply with the Sh request as XDMS has only provided the IMPU, and the IMPU points to two repositories A and B: Repository A for IMPI1 and Repository B for IMPIn.    5. HSS sends a UDA (5012 DIAMETER_UNABLE_TO_COMPLY) to XDMS    6. The XDMS sends back a negative 5xx HTTP response to AP    7. AP forwards the negative 5xx HTTP response to IMPI1.
FIG. 6 illustrates a scenario involving a MultiSim with IMPI1 and IMPI2 but with a single IMPU and a single repository data containing service data for both IMPI1 and IMPIn. Using the XCAP approach described above, it is not possible for IMPI1 (UE1) to access correctly its service data within the single repository as the repository is also storing IMPIn service data. Without logical segregation of IMPI1 and IMPIn service data within the repository it is not possible for a MultiSim subscription with single IMPU to access service data. This is illustrated further in the signalling flow of FIG. 7.
Problems also arise for a Single Sim scenario in which a number of IMPUs (n) share the same repository data. As the Ut interface only provides the X-3GPP-Asserted-Identity=IMPU, it is not possible to access within the repository data the correct service data for the IMPI and IMPU combination. This scenario and problem are illustrated in FIGS. 8 and 9.